Hmm yeah as Flotch says, that is an old test patch.
Trouble is now as it has messed up some files I think you need to reinstall a fresh version 0.7D
Trouble is now as it has messed up some files I think you need to reinstall a fresh version 0.7D
I made a step forward in tyre physics last week. Although there is still a lot to do, I thought it would be good to try a test of the 1000Hz updates this week (nothing to do with tyre physics but may help with separating physics and graphics onto separate threads, along with other advantages). I was able to get a first version running in a day and worked another day searching through references to 'turns' and fixing various issues where the code had assumed that each turn was 0.01s. Now it's coded in a flexible way so I can change the update rate and recompile, to get comparisons between the 100Hz and 1000Hz versions. Actually there's a bit more searching to do but I was able to run some tests.
The good results:
The moving image is noticeably smoother. Different people have a different sensitivity to the stutter that results from the mismatch between graphical frame rate and physical update rate. As mentioned before, with a 60Hz frame rate and 100Hz physics rate, the graphical frames have physics updates like this: 2, 2, 1, 2, 2, 1...
This is known to be a worse problem in VR, with 90Hz frame rate, there are 8 graphical frames with 1 physics update, then the 9th graphical frame has 2 physics updates. So there is an extra step 10 times every second which is unpleasant when you look left or right out of your car and see scenery moving by.
That stutter can be reproduced without VR by a simple camera movement test. In full screen with vertical sync enabled, park a car in the open (e.g. at autocross) enter free view mode and look down at the car. Use left mouse button to move the car in circles or from left to right. You can see a sort of stutter or blurring at the edges of the car, or with the paint lines on the road.
With the 1000Hz version, the physics updates per graphical frame are 17, 17, 16, 17, 17, 16... which seems a lot smoother and the stutter is no longer noticeable.
Also super slow motion looked nice. Even when slowed to 1/8 speed, the physics frame rate is still 125 Hz which is more than the frame rate, so the slow motion car looks smooth.
Physics checks with the environment are more frequent, for example at 100mph we are at about 45m/s so with 100Hz updates, environment checks are every 45cm. With 1000Hz updates the environment checks are every 4.5cm. This looked good in force view as the AI driver's wheels drove over the kerbs though I have not tested FF. I don't expect to feel a difference but it could be good for people with high end DD wheels.
The bad results:
So far the CPU usage is too high. I ran a test with 10 AI cars at the start line in South City. As expected the environment checks used 10 times the CPU. The movement update also took more CPU time due to not being in a tight loop (although there are the same number of movement updates, known as sub-updates in the 100Hz version). This is assumed to be related to the cache. It's more efficient when the CPU runs a tight loop on the same data, compared with going through all the other cars and then going through all sorts of other code and data before coming back to the same data again the next frame.
Results when changing from 100Hz to 1000Hz:
10 cars on grid at new South City, physics code % of CPU time
environment checks - 2.2 up to 20.3
movement update - 3.9 up to 9.40
What next:
The movement update may be improved a little because there are no actual sub-updates, some things could be done more efficiently but I do not expect a very significant improvement.
The environment check CPU time increase is not acceptable. This 20% CPU usage is only with 10 cars and it gets far worse when the cars go through the underpass. But nearly all these environment checks are actually parts of the car (contact points and wheels) checking for collisions with nearby objects and not getting a collision at all. This suggests there is a lot of scope for optimisation. The idea is to avoid the detailed collision check in most cases if there isn't any chance of a collision. Of course, this is done to some extent already but a more accurate method is needed. The first thing to try is "Oriented Bounding Boxes" for the track segments. It's the obvious choice as it could reduce a lot of checking against fences, barriers and road surfaces. I'll need to try that and see how it goes before trying to think of other types of optimisation.
The good results:
The moving image is noticeably smoother. Different people have a different sensitivity to the stutter that results from the mismatch between graphical frame rate and physical update rate. As mentioned before, with a 60Hz frame rate and 100Hz physics rate, the graphical frames have physics updates like this: 2, 2, 1, 2, 2, 1...
This is known to be a worse problem in VR, with 90Hz frame rate, there are 8 graphical frames with 1 physics update, then the 9th graphical frame has 2 physics updates. So there is an extra step 10 times every second which is unpleasant when you look left or right out of your car and see scenery moving by.
That stutter can be reproduced without VR by a simple camera movement test. In full screen with vertical sync enabled, park a car in the open (e.g. at autocross) enter free view mode and look down at the car. Use left mouse button to move the car in circles or from left to right. You can see a sort of stutter or blurring at the edges of the car, or with the paint lines on the road.
With the 1000Hz version, the physics updates per graphical frame are 17, 17, 16, 17, 17, 16... which seems a lot smoother and the stutter is no longer noticeable.
Also super slow motion looked nice. Even when slowed to 1/8 speed, the physics frame rate is still 125 Hz which is more than the frame rate, so the slow motion car looks smooth.
Physics checks with the environment are more frequent, for example at 100mph we are at about 45m/s so with 100Hz updates, environment checks are every 45cm. With 1000Hz updates the environment checks are every 4.5cm. This looked good in force view as the AI driver's wheels drove over the kerbs though I have not tested FF. I don't expect to feel a difference but it could be good for people with high end DD wheels.
The bad results:
So far the CPU usage is too high. I ran a test with 10 AI cars at the start line in South City. As expected the environment checks used 10 times the CPU. The movement update also took more CPU time due to not being in a tight loop (although there are the same number of movement updates, known as sub-updates in the 100Hz version). This is assumed to be related to the cache. It's more efficient when the CPU runs a tight loop on the same data, compared with going through all the other cars and then going through all sorts of other code and data before coming back to the same data again the next frame.
Results when changing from 100Hz to 1000Hz:
10 cars on grid at new South City, physics code % of CPU time
environment checks - 2.2 up to 20.3
movement update - 3.9 up to 9.40
What next:
The movement update may be improved a little because there are no actual sub-updates, some things could be done more efficiently but I do not expect a very significant improvement.
The environment check CPU time increase is not acceptable. This 20% CPU usage is only with 10 cars and it gets far worse when the cars go through the underpass. But nearly all these environment checks are actually parts of the car (contact points and wheels) checking for collisions with nearby objects and not getting a collision at all. This suggests there is a lot of scope for optimisation. The idea is to avoid the detailed collision check in most cases if there isn't any chance of a collision. Of course, this is done to some extent already but a more accurate method is needed. The first thing to try is "Oriented Bounding Boxes" for the track segments. It's the obvious choice as it could reduce a lot of checking against fences, barriers and road surfaces. I'll need to try that and see how it goes before trying to think of other types of optimisation.
Good question but the answer is quite unknown at the moment.
In fact it's not really 10 times the workload, although there is certainly more workload. The current LFS does 'subupdates' within the physics updates. The main reason for that is the wheel object suspended between a strong spring pushing down (suspension) and another stiff spring pushing up, the physics needed a higher update rate to avoid instability in that and I think on some other areas too.
In the public version that subupdate rate is 20 times the overall physics rate. So there is a part of the car already updating at 2000 Hz. In the development version there are 10 subupdates so it's already running at 1000 Hz.
But the ray checks vs world objects (and other cars) only happen at the base physics rate, so that is only at 100 Hz. This part might be 10 times the workload, as you suggest. There is also an advantage in the existing version that the subupdates are done as a tight loop on an individual car so I assume this is good for cache access. I'm sure that expanding the tight subupdate loop into full physics frame loops will be less efficient for cache hits.
Diagram:
Current:
0.00 - Environment check for all cars
Physics update for car 1 (10 subupdates)
Physics update for car 2 (10 subupdates)
...
0.01 - Environment check for all cars
Physics update for car 1 (10 subupdates)
Physics update for car 2 (10 subupdates)
...
[0.02s elapsed]
Proposed:
0.000 - Environment check for all cars
Physics update for car 1 (1 subupdate)
Physics update for car 2 (1 subupdate)
...
0.001 - Environment check for all cars
Physics update for car 1 (1 subupdate)
Physics update for car 2 (1 subupdate)
...
[0.002s elapsed]
I really can't guess how much more work this would be. The environment checks may be 10 times, as you pointed out. I think some optimisations might help with this. The subupdates shouldn't cost any more calculations but presumably will be slowed by memory access as the 'subupdates' are no longer done on a tight loop for a single car.
I think the way forward is to go through the program, adjusting it where necessary so that I can test the two scenarios above with a simple program change (update frequency & number of subupdates). Then test the CPU usage for the physics loop and see how it compares. That sounds simple but as you may imagine, I haven't always put in a suitable multiplier when trying to work quickly to release updates. There is some code around like "do this for 100 updates" which I knew would take 1 second. But now such code needs to be changed to the equivalent of "do this for 1/update_time updates" etc. It shouldn't take too long to get for a first test just to see how the CPU usage is affected. Hopefully it's just a search for the word "turns" and look at each one to see if it needs a fix.
The word "turns" (not case sensitive) appears 671 times
The word "Turn" (case sensitive) appears 785 times
Unfortunately the word "turn" in lower case is part of the word "return" which appears 9687 times.
But don't worry, I should be able to devise reasonable strategies to find the relevant lines to check.
In fact it's not really 10 times the workload, although there is certainly more workload. The current LFS does 'subupdates' within the physics updates. The main reason for that is the wheel object suspended between a strong spring pushing down (suspension) and another stiff spring pushing up, the physics needed a higher update rate to avoid instability in that and I think on some other areas too.
In the public version that subupdate rate is 20 times the overall physics rate. So there is a part of the car already updating at 2000 Hz. In the development version there are 10 subupdates so it's already running at 1000 Hz.
But the ray checks vs world objects (and other cars) only happen at the base physics rate, so that is only at 100 Hz. This part might be 10 times the workload, as you suggest. There is also an advantage in the existing version that the subupdates are done as a tight loop on an individual car so I assume this is good for cache access. I'm sure that expanding the tight subupdate loop into full physics frame loops will be less efficient for cache hits.
Diagram:
Current:
0.00 - Environment check for all cars
Physics update for car 1 (10 subupdates)
Physics update for car 2 (10 subupdates)
...
0.01 - Environment check for all cars
Physics update for car 1 (10 subupdates)
Physics update for car 2 (10 subupdates)
...
[0.02s elapsed]
Proposed:
0.000 - Environment check for all cars
Physics update for car 1 (1 subupdate)
Physics update for car 2 (1 subupdate)
...
0.001 - Environment check for all cars
Physics update for car 1 (1 subupdate)
Physics update for car 2 (1 subupdate)
...
[0.002s elapsed]
I really can't guess how much more work this would be. The environment checks may be 10 times, as you pointed out. I think some optimisations might help with this. The subupdates shouldn't cost any more calculations but presumably will be slowed by memory access as the 'subupdates' are no longer done on a tight loop for a single car.
I think the way forward is to go through the program, adjusting it where necessary so that I can test the two scenarios above with a simple program change (update frequency & number of subupdates). Then test the CPU usage for the physics loop and see how it compares. That sounds simple but as you may imagine, I haven't always put in a suitable multiplier when trying to work quickly to release updates. There is some code around like "do this for 100 updates" which I knew would take 1 second. But now such code needs to be changed to the equivalent of "do this for 1/update_time updates" etc. It shouldn't take too long to get for a first test just to see how the CPU usage is affected. Hopefully it's just a search for the word "turns" and look at each one to see if it needs a fix.
The word "turns" (not case sensitive) appears 671 times
The word "Turn" (case sensitive) appears 785 times
Unfortunately the word "turn" in lower case is part of the word "return" which appears 9687 times.
But don't worry, I should be able to devise reasonable strategies to find the relevant lines to check.
Last edited by Scawen, .
Thank you for the tests.
I've uploaded a last chance test patch C6 as we plan to release the full version this afternoon.
Changes from C5 to C6:
Interface:
FIX: Virtual keyboard full of question marks in Greek or Cyrillic
List of events:
Lock icon reduces width of Join button to share the usual width
Generic 'play' character added for other live streaming services
I've uploaded a last chance test patch C6 as we plan to release the full version this afternoon.
Changes from C5 to C6:
Interface:
FIX: Virtual keyboard full of question marks in Greek or Cyrillic
List of events:
Lock icon reduces width of Join button to share the usual width
Generic 'play' character added for other live streaming services
That is now available in Test Patch C5:
https://www.lfs.net/forum/thread/98309
https://www.lfs.net/forum/thread/98309
Changes in test patch C5:
List of events:
YouTube and Twitch links are now shown as icons instead of names
A lock icon is displayed beside Join button if password required
Mods screen:
Mod name was not always shown as selected when entering mods screen
Misc:
FIX: Corrected width of characters in text dialog code page view
List of events:
YouTube and Twitch links are now shown as icons instead of names
A lock icon is displayed beside Join button if password required
Mods screen:
Mod name was not always shown as selected when entering mods screen
Misc:
FIX: Corrected width of characters in text dialog code page view
Thanks for the report. I've now fixed this so it will be in the next test patch (after C4).
Thanks for the report. This is fixed in Test Patch C2:
https://www.lfs.net/forum/thread/98309
https://www.lfs.net/forum/thread/98309
I've gone with the cyan version in test patch C4.
It's not implemented on the web side so you won't see anything yet.
It's not implemented on the web side so you won't see anything yet.
The fix is available for testing in Test Patch C4: https://www.lfs.net/forum/thread/98309
OK I think I have a solution. Luckily I have an old FF joystick to test.
I tried your proposed fast fix: abs(nXForce) -> nXForce
But that doesn't work properly - it resulted in reverse force when steering left.
So I tried keeping the change you suggested but also set the direction to 'right' always. This seems to work.
CODE:
This seems to have the same result on the FF joystick and I guess it would work on your wheel.
I tried your proposed fast fix: abs(nXForce) -> nXForce
But that doesn't work properly - it resulted in reverse force when steering left.
So I tried keeping the change you suggested but also set the direction to 'right' always. This seems to work.
CODE:
old:
rglDirection[0] = nXForce;
rglDirection[1] = nYForce;
cf.lMagnitude = abs(nXForce);
new:
rglDirection[0] = 1;
rglDirection[1] = 0;
cf.lMagnitude = nXForce;This seems to have the same result on the FF joystick and I guess it would work on your wheel.
That is fixed in Test Patch C3: https://www.lfs.net/forum/thread/98309
A crash fix and a few minor updates in Test Patch C3
For the keyboard steering with arrow keys bug, please try test patch C2:
https://www.lfs.net/forum/thread/98309
https://www.lfs.net/forum/thread/98309
For the keyboard steering with arrow keys bug, please try test patch C2:
https://www.lfs.net/forum/thread/98309
https://www.lfs.net/forum/thread/98309
Test Patch C2 (now C6)
NOTE: OFFICIAL VERSION 0.7D IS NOW AVAILABLE
WARNING: THIS IS A TEST
PLEASE TEST BEFORE YOU POST
Hello Racers,
Here is a new test patch: 0.7C6
The changes are listed below.
0.7C6 is COMPATIBLE with 0.7C
- You CAN connect online with 0.7C
- You CAN play replays from 0.7C
Please back up or rename your LFS.exe from 0.7C so you can revert to it if necessary.
Changes from 0.7C5 to 0.7C6:
Interface:
FIX: Virtual keyboard full of question marks in Greek or Cyrillic
List of events:
Lock icon reduces width of Join button to share the usual width
Generic 'play' character added for other live streaming services
Changes from 0.7C to 0.7C5:
List of events:
Time to live stream is displayed if it starts in less than 1 hour
Displays current and max connections on host if any are connected
Live stream service links are now shown as icons instead of names
A lock icon is displayed beside Join button if password required
Mods screen:
If host has a limited list of mods the filters are set to show all
Page Up / Page Down keys move a whole page (5 lines instead of 4)
FIX: Selected mod's name was not always identified as selected
Force feedback:
Change in force feedback code for devices that report two FF axes
- to fix a problem with some wheels with inverted FF turning left
Interface:
Click "Join" when no official cars allowed now enters mods screen
FIX: Crash after selecting a driver name from Join Specific Host
FIX: Assigned arrow keys adjusted brake balance (etc) while driving
FIX: Viewer button was available in garage during welcome sequence
FIX: Corrected width of characters in text dialog code page view
INSTALLATION:
A FULL version of LFS 0.7C must already be installed
To install the PATCH using the SELF EXTRACTING ARCHIVE:
1) Move or save the patch into your main LFS folder
2) Double click the patch to extract it to that folder
3) When you see "Confirm File Replace" select "Yes to All"
4) Now you can start LFS in the normal way
NOTE: You can see if the patch is correctly installed when you run
the program (LFS.exe). At the bottom of the entry screen: 0.7C6
DOWNLOAD:
PATCH 0.7C TO 0.7C6 (SELF EXTRACTING ARCHIVE) (If you already have 0.7C)
EDIT: Link removed, full version is now available (1.0 MB)
WARNING: THIS IS A TEST
PLEASE TEST BEFORE YOU POST
Hello Racers,
Here is a new test patch: 0.7C6
The changes are listed below.
0.7C6 is COMPATIBLE with 0.7C
- You CAN connect online with 0.7C
- You CAN play replays from 0.7C
Please back up or rename your LFS.exe from 0.7C so you can revert to it if necessary.
Changes from 0.7C5 to 0.7C6:
Interface:
FIX: Virtual keyboard full of question marks in Greek or Cyrillic
List of events:
Lock icon reduces width of Join button to share the usual width
Generic 'play' character added for other live streaming services
Changes from 0.7C to 0.7C5:
List of events:
Time to live stream is displayed if it starts in less than 1 hour
Displays current and max connections on host if any are connected
Live stream service links are now shown as icons instead of names
A lock icon is displayed beside Join button if password required
Mods screen:
If host has a limited list of mods the filters are set to show all
Page Up / Page Down keys move a whole page (5 lines instead of 4)
FIX: Selected mod's name was not always identified as selected
Force feedback:
Change in force feedback code for devices that report two FF axes
- to fix a problem with some wheels with inverted FF turning left
Interface:
Click "Join" when no official cars allowed now enters mods screen
FIX: Crash after selecting a driver name from Join Specific Host
FIX: Assigned arrow keys adjusted brake balance (etc) while driving
FIX: Viewer button was available in garage during welcome sequence
FIX: Corrected width of characters in text dialog code page view
INSTALLATION:
A FULL version of LFS 0.7C must already be installed
To install the PATCH using the SELF EXTRACTING ARCHIVE:
1) Move or save the patch into your main LFS folder
2) Double click the patch to extract it to that folder
3) When you see "Confirm File Replace" select "Yes to All"
4) Now you can start LFS in the normal way
NOTE: You can see if the patch is correctly installed when you run
the program (LFS.exe). At the bottom of the entry screen: 0.7C6
DOWNLOAD:
PATCH 0.7C TO 0.7C6 (SELF EXTRACTING ARCHIVE) (If you already have 0.7C)
EDIT: Link removed, full version is now available (1.0 MB)
Last edited by Scawen, .
Thanks for the report - I should disable the viewer button in the welcome sequence.
I can't see any difference between this version and version B regarding arrow keys adjustment of brake balance / and anti roll bar.
As I can't find anything from a quick test, can you tell me which version you go back to, to see a different result?
Last edited by Scawen, .
Well... it would be a lot easier than the current stereoscopic 3D mirror system! But it would be quite a system, with some new features like the ability to set camera positions and field of view, etc. I know a lot of people want this feature and I would like to do it, but it's another other of those things that is harder to do right now as all the changes would have to be done in both the current version and the development version. So at this point it's best to get on with the tyre physics so we can get back to a single version.
I've updated the editor to a new B12 version. It's a minor update - really just a test after merging all the recent LFS updates.
Text entry system language support was improved in LFS
Better alignment of entry screen buttons
Smaller LFS logo on entry screen
https://www.lfs.net/forum/thread/97865
You can set that in Options... Display... Interface - Opacity (below 'Big Button' colour)
I've uploaded a new test patch B12, with minor updates. I've started looking into the tyre physics again. At this point I would like to release a full version with the latest changes from the test patches.
B12 has a fix and an option and all the recent changes have been fully merged with the development version. That is quite a big operation and always involves a few lines being changed, so it's worth testing. Also translations have been updated.
Command /eventlist=no to disable list of events
Corrected opacity of background buttons in mods screen
Can receive one more text field to show beside "Sign up"
Updated translations - thank you translators!
https://www.lfs.net/forum/thread/97772
Thanks, but please can you post that on the thread "How to improve attendance for scheduled events?" system as that would be on Victor's side, and I guess he might not follow this test patch thread.
https://www.lfs.net/forum/post/1996736#post1996736
What about if you could choose to receive an SMS about it? E.g. choose SMS and/or email notification?
https://www.lfs.net/forum/post/1996736#post1996736
What about if you could choose to receive an SMS about it? E.g. choose SMS and/or email notification?
Test Patch B11
Improved appearance of entry screen upcoming events list
Can use up / down / page up / page down / home / end keys
FIX: Mods screen flickered while downloading mod images
https://www.lfs.net/forum/thread/97772
Improved appearance of entry screen upcoming events list
Can use up / down / page up / page down / home / end keys
FIX: Mods screen flickered while downloading mod images
https://www.lfs.net/forum/thread/97772
Test Patch B11
Improved appearance of entry screen upcoming events list
Can use up / down / page up / page down / home / end keys
FIX: Mods screen flickered while downloading mod images
https://www.lfs.net/forum/thread/97772
Improved appearance of entry screen upcoming events list
Can use up / down / page up / page down / home / end keys
FIX: Mods screen flickered while downloading mod images
https://www.lfs.net/forum/thread/97772
Test Patch B10:
List of upcoming events is displayed on the entry screen
- click event name to visit the event page at lfs.net
- signup and live stream links are provided if relevant
- a "Join" button is also available if the host is running
https://www.lfs.net/forum/thread/97772
List of upcoming events is displayed on the entry screen
- click event name to visit the event page at lfs.net
- signup and live stream links are provided if relevant
- a "Join" button is also available if the host is running
https://www.lfs.net/forum/thread/97772
Test Patch B10:
List of upcoming events is displayed on the entry screen
- click event name to visit the event page at lfs.net
- signup and live stream links are provided if relevant
- a "Join" button is also available if the host is running
https://www.lfs.net/forum/thread/97772
List of upcoming events is displayed on the entry screen
- click event name to visit the event page at lfs.net
- signup and live stream links are provided if relevant
- a "Join" button is also available if the host is running
https://www.lfs.net/forum/thread/97772
Nice to see these event images appearing. I'm hoping to release a test patch today.
Organisers, if your event requires people to sign up, please make sure that is set correctly in the season information. If people see "No signup required" then I'm sure they will not even try to sign up. Example: the MRc RX on Sunday. The website and the in-game calendar say "No signup required" but apparently you do have to sign up. https://www.lfs.net/forum/post/1994626#post1994626
Organisers, if your event requires people to sign up, please make sure that is set correctly in the season information. If people see "No signup required" then I'm sure they will not even try to sign up. Example: the MRc RX on Sunday. The website and the in-game calendar say "No signup required" but apparently you do have to sign up. https://www.lfs.net/forum/post/1994626#post1994626
Last edited by Scawen, .
FGED GREDG RDFGDR GSFDG